1. Field of the Invention
This invention relates generally to communication protocols, and more particularly to communication protocols that connect computer systems to peripheral devices.
2. Description of the Related Art
A basic component of a host computer system is the peripheral device. Peripheral devices come in many forms, such as, hard drives, CD-ROMs, optical discs, and the like. To enable communication between the host computer system and its peripheral devices, data transfer protocols such as IDE and SCSI are used. As is well known, the SCSI protocol is designed for high bandwidth and performance demanding environments due to its superior data transfer rates. On the other hand, the IDE protocol is designed to be a lower cost alternative to the SCSI protocol. Thus, computer systems that are designed with a budget in mind tend to implement IDE peripheral devices, but suffer in terms of performance.
FIG. 1 illustrates a typical host computer system 12 that implements peripheral devices 14 and 18. As shown, peripheral device 14 is an internal peripheral device, which can be either IDE or SCSI. Peripheral device 18, on the other hand, is an external device. Because IDE devices implement parallel data transfer buses, IDE peripheral devices are generally manufactured in the form of internal devices. Consequently, in order to connect an external peripheral device, such as device 18 to the host computer system 12, a host adapter needs to be installed into the host computer system 12. To implement external devices, a SCSI host adapter can be connected to the host computer system 12 by way of a PCI bus. The SCSI host adapter can then allow communication over a SCSI bus 16 to the peripheral device 18, which also needs to be a SCSI device. Although, the implementation of SCSI devices can add cost to the system, thus discouraging cost sensitive consumers from implementing external peripheral devices.
In order to maintain cost at a minimum, most computer motherboards come integrated with two IDE connectors. As is well known, each IDE connector can then support a short and bulky IDE parallel cable that itself has two IDE connectors. Each of the two IDE connectors can then connect up to a particular internal IDE peripheral device. For each pair of IDE devices, one device is designated as a master device and the other is designated as a slave device. This designation enables a particular IDE hard drive that is connected to a master connection to be designated as a boot device. Thus, the master IDE device, which is in the form of a hard drive is typically the boot device that contains an operating system (OS) image. Following this implementation, such computer systems can add more internal peripheral devices.
As a result, the IDE protocol provides a low end solution that has limitations on performance such as speed, cable length, and extendibility to external devices. In view of the foregoing, there is a need for a more robust protocol that can deliver improved communication performance, can be extended to external devices, provides for longer and less bulky cable lengths and is a cost sensitive solution that enables the manufacturer of such devices at cost structures that are about equivalent to today""s low end IDE solutions.
Broadly speaking, the present invention fills these needs by providing an advanced serial protocol (ASP) that defines a more robust data transmission environment for communication between host computers and peripheral devices. It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium. Several inventive embodiments of the present invention are described below.
In one embodiment, a method for communicating serial data between a host computer and a peripheral device is disclosed. The packet for communication between the host computer and the peripheral device includes: (a) a synchronization field; (b) a packet type (PT) field following the synchronization field, the packet type field defining an error correction type for the packet; (c) a byte count (BC) field for defining a length of data for the packet; (d) a data type (DT) field for defining whether the data is one of link control, device control, and device data; (e) a data field; and (f) a CRC field for error checking the data in the data field.
In another embodiment, a method for communicating data and control from a host computer to a device is disclosed. The method includes generating an OUTDATA0/1 packet at the host computer. The method then includes transmitting the OUTDATA0/1 packet to the device. The device responding to the OUTDATA0/1 packet with a handshake, and the handshake includes one of an ACK, a NACK, and an ALERT. The ACK being indicative that the OUTDATA0/1 packet was received without errors and a next packet in a sequence of packets can be sent to the device, the NACK being indicative that the OUTDATA0/1 packet was received without errors but a re-transmission should be attempted, and the ALERT being indicative of an error condition at the device and a re-transmission should not be attempted.
In yet a further embodiment, another method for communicating data and control from a host computer to a device is disclosed. The method includes generating a packet at the host computer and transmitting the packet to the device. The device responding to the packet with a handshake, and the handshake includes one of an ACK, a NACK, and an ALERT. The ACK is indicative that the packet was received without errors and a next packet in a sequence of packets can be sent to the device, the NACK is indicative that the packet was received without errors but a re-transmission should be attempted, and the ALERT is indicative of an error condition at the device and a re-transmission should not be attempted. In this embodiment, the packet has a packet format including: (a) a synchronization field; (b) a packet type (PT) field following the synchronization field; (c) a byte count (BC) field for defining a length of data for the packet; (d) a data type (DT) field for defining whether the data is one of link control, device control, and device data; and (e) a data field.
In still a further embodiment, a method for communicating data and control from a host computer to a block oriented peripheral device is disclosed. The method includes generating a OUTDATA0/1 packet at the host computer, and transmitting the OUTDATA0/1 packet to the block oriented peripheral device. The block oriented peripheral device responds to the OUTDATA0/1 packet with a handshake, and the handshake includes one of an ACK, a NACK, and an ALERT. The ACK being indicative that the OUTDATA0/1 packet was received without errors and a next packet in a sequence of packets can be sent to the block oriented peripheral device, the NACK being indicative that the OUTDATA0/1 packet was received without errors but a re-transmission should be attempted, and the ALERT being indicative of an error condition at the block oriented peripheral device and a re-transmission should not be attempted.
The advantages of the present invention are numerous. Most notably, the ASP bus is specified to be an industry standard extension to the PC architecture which will be a replacement or alternative for the IDE bus. ASP will provide higher speeds and more fault tolerant operations while not requiring a complete change to the current IDE command structure. The ASP provides exceptional ease of use for PC peripheral expansion and is a low-cost solution that supports fast transfer rates. ASP is capable of being integrated in commodity device technology, and provides a standard interface capable of quick diffusion into existing products. ASP is designed to be an extension of the IDE protocol and ATA/ATAPI command set for the attachment of block oriented devices.
ASP is also extendable in terms of the speed that can be achieved. Today, IDE can only operate to 16 MBps (33 MBps is defined but has not yet been used). Some embodiments of the ASP will enable link communication up to about 960 MBps without adversely affecting the protocol. Also, ASP will provide some performance features such as overlapped commands to different devices, DMA transfers only and dynamic allocation of bandwidth to faster devices when needed. Also ASP provides more robust reliability with the inclusion of CRC checking on the data and true plug and play capability.